home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 15671 < prev    next >
Encoding:
Text File  |  1996-08-05  |  2.0 KB  |  58 lines
  1. Path: news.compuserve.com!newsmaster
  2. From: Philippe Verdy <100105.3120@compuserve.com>
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: Is it OK to delete const *type pointers?
  5. Date: 7 Apr 1996 22:39:40 GMT
  6. Organization: CompuServe Incorporated
  7. Message-ID: <4k9g7c$fl9@arl-news-svc-5.compuserve.com>
  8. NNTP-Posting-Host: ad04-110.compuserve.com
  9.  
  10. Enno Sandner <enno@intellektik.informatik.th-darmstadt.de> s'Θcrit :
  11. > Acme Instant Dehydrated Boulder Kit wrote:
  12. > > 
  13. > > Some compilers let me do this, others do not. What I would like to know is,
  14. > > what does Stroustrup think? I.e. is it written somewhere in the ARM (I checked
  15. > > but can't find it) or in the draft standard? If somoene could e-mail me a
  16. > > quote or a pointer to a place where I can read where it says such a thing
  17. > > should or should not be allowed, I would appreciate it!
  18. > > 
  19. > > const int* array= new int[30];
  20. > > delete[] array;
  21. > > 
  22. > > MSVC says "can not delete const*"
  23. > > Some versions of G++ also don't let me do this.
  24. > > 
  25. > > Is deleting an object technically considered changing that object's value?
  26. > > 
  27. > 
  28. > The standard doesn't specify this (5.3.5.4):
  29. > ... It is unspecified whether the deletion of an object changes its
  30. >     value. ...
  31. > 
  32. > According to the DWP a dtor can be invoked even for a const-object
  33. > (12.4 class.dtor). Thus I would say the above code should compile.
  34. > 
  35. >     Enno
  36.  
  37. The following compiles under BC++ 4.0, 4.5, and 5.0:
  38. int const *ptr = new int(1);
  39. int const *arr = new int[10];
  40. main()
  41. {
  42.   delete ptr;
  43.   delete[] arr;
  44. }
  45.  
  46. Being const does not mean the object is read-only. Nor does
  47. it mean that its value won't change. Nor does it mean that
  48. it cannot be deleted.
  49. It only forbids writing to it directly without an
  50. explicit const_cast<>. This cast however is an operator
  51. which can be overriden to enforce const-ness, by returning
  52. a non-const copy of the referenced object.
  53.  
  54. Const-ness is a security helper, which also avoids unnecessary
  55. invocation of copy constructors, while specifying more
  56. precisely the intended objects interface and the set of
  57. operations which can occur on them.
  58.